home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / dcom / modems-part1 / 8005 < prev    next >
Encoding:
Internet Message Format  |  1996-08-05  |  4.9 KB
  1. Path: news.ultranet.com!usenet
  2. From: "Albert P. Belle Isle" <belleisl@cerberus-sys.com>
  3. Newsgroups: alt.winsock.trumpet,alt.winsock,comp.dcom.modems
  4. Subject: Re: Frame check error
  5. Date: Fri, 15 Mar 1996 12:07:10 -0500
  6. Organization: Cerberus Systems, Inc.
  7. Message-ID: <3149A3BE.7CD2@cerberus-sys.com>
  8. References: <4hhg08$c2t@mcmail.CIS.McMaster.CA> <4iaa9h$ntb@server.cntfl.com>
  9. NNTP-Posting-Host: apb-p5-90.cerberus-sys.com
  10. Mime-Version: 1.0
  11. Content-Type: text/plain; charset=us-ascii
  12. Content-Transfer-Encoding: 7bit
  13. X-Mailer: Mozilla 2.01 (Win16; I)
  14.  
  15. John Farrell wrote:
  16. > 
  17. > I have the same problem, and I'm using a 28.8 USR on a 486/66 clone.
  18. > I know, in a general way, what causes the error, what I'm wondering is
  19. > how to fix it.  Or if it is unfixable.  I have tried adding some stuff
  20. > to my systeml.ini file, and to my config.sys; but it didn't seem to do
  21. > much good.  My settings are MTU 1500, TCP RWIN 4096, TCP MSS 1460,
  22. > and I have the baud rate on trumpet setup at 38400.  Would messing
  23. > around with the com port settings in control panel help any?  I tried
  24. > increasing the baud rate there, but it didn't seem to make any
  25. > difference, and I even messed around with the timeslice and that other
  26. > stuff in there, but being a civil engineer all I know how to do is
  27. > design a bridge, not fix my telcom stuff.
  28. > 
  29. > I've read that the proper UART will help, but I thought that came on
  30. > the card with the USR 28.8, also I have heard that one needs to be
  31. > sure that the modem is set up for error correction.  How?
  32. > 
  33. > I've read that this is a problem caused by the way windows works.  Can
  34. > it be cured on this machine, or on any machine running 3.1?
  35. > 
  36. > What about windows 95?
  37.  
  38. John:
  39.  
  40. Many of the settings in your TCP/IP stack deal with things like the 
  41. maximum number of data bytes that should be sent to you in a single 
  42. packet (a TCP/IP transaction).
  43.  
  44. In a dial-in stack (like Trumpet WinSock) there is also a mechanism for
  45. fooling the TCP/IP part of the stack into thinking that the packets full
  46. of bytes it finds in the area of your RAM that it uses for buffers got there
  47. from a direct TCP/IP connection to the Internet - even though they really 
  48. came through your RS232 ("com") port, after being transmitted through a pair
  49. of modems communicating over an analog telephone connection. The lower-level
  50. protocol for doing this is either PPP or one of the versions of SLIP.
  51.  
  52. PPP wraps 1500-byte IP transmission units, along with a check-sum, into
  53. data "frames" which are sent over your access provider's RS232 serial
  54. port, through his modem to your modem, then through your serial port into
  55. the portion of your machine's memory containing the buffers TCPMan(ager)
  56. has allocated as the logical "socket" for a particular TCP/IP-using
  57. application program.
  58.  
  59. This "data link layer" underneath the TCP/IP (packet) transactions must
  60. flawlessly send every byte, without errors, if the packet is to be
  61. successfully reassembled in your buffers. If it isn't, TCP will wait for
  62. a re-transmission, wasting a lot of time. UDP, which doesn't account for
  63. each byte and is used for things like RealAudio, will just loose the packet.
  64.  
  65. If the protocol you're using to simulate the direct TCP/IP connection is
  66. the Point-to-Point Protocol, you'll see "PPP Frame Check Error" in PPP
  67. Trace, because the check-sum your machine computed didn't match the one
  68. included with the data bytes in the PPP frame.
  69.  
  70. One source of data link layer errors is individual byte-garbling by noise
  71. on the phone line that's not corrected by your modem. Be sure that your
  72. modem's init string has not turned-off its V42 error correction.
  73.  
  74. A more common cause of data link layer errors is when your modem, having
  75. been promised by your com port settings that your CPU will empty bytes
  76. from the UART at a particular rate, accepts more bytes from your ISP's
  77. modem and writes them on top of the ones your CPU still hasn't gotten
  78. around to emptying from the UART. This is called a com overrun error.
  79.  
  80. In any case, the TCP layer is a user of what comes over the data link layer, 
  81. and its parameter settings (MSS/RWIN/RTOmax) have no more influence on
  82. this problem than changing the size of the viewing window in the browser
  83. software that uses the results of the TCP transactions. You have to get 
  84. rid of the byte-dropping (overruns) or byte-garbling (modem symbol errors)
  85. to make a solid data link layer, before trying to run higher-layer software
  86. on top of it.
  87.  
  88. I've tried to elaborate on this in the sections of the below-listed FAQ 
  89. entitled "MTU/MSS/RWIN vs Com Overrun Errors" and "SLIP, PPP and Frame 
  90. Check Errors," if you're interested in more details. The section entitled
  91. "Com Port Overrun Errors" deals with some solutions you might try.
  92.  
  93. Hope this helps.
  94.  
  95. Regards,
  96.  
  97. Al
  98.  
  99.  
  100.  
  101. -- 
  102. ==================================================================
  103. Albert P. Belle Isle
  104. Cerberus Systems, Inc.
  105.  
  106. Al's Winsock Tuning FAQ -
  107.        http://www.cerberus-sys.com/~belleisl/mtu_mss_rwin.html
  108. ==================================================================
  109.